home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Internet Tools 1993 July / Internet Tools.iso / iso9660 / mail / pine / imap.arc / text0003.txt < prev    next >
Encoding:
Text File  |  1993-07-02  |  4.5 KB  |  89 lines
  1. > >   1. access to the host's quota control mechanism, where one exists
  2. > This is difficult to do in any sort of general way.  One problem is that
  3. > different implementations have different interpretations of quotas.
  4.  
  5. why not return percentage of quota used so far, according to the system
  6. (e.g. use the 'quota' command on SunOS) - if the system is inaccurate,
  7. that's too bad, but it may be accurate.
  8.  
  9. > Modern-day c-client does detect and clean up properly when quota problems hit.
  10.  
  11. Er, how? Do you mean the c-client in the Washington distribution has
  12. agreed a private protocol (e.g. a text in a BAD message) to pass this
  13. information on?
  14.  
  15. > >   5. forwarding (user-initiated, i.e. in a session)
  16. > Could you explain this?  I don't quite understand what you mean.  Do you mean
  17. > forwarding a message or altering your mail forwarding or ??
  18.  
  19. I mean sending on a mail message at the server (i.e. in a mailbox) without
  20. having it delivered to the client and then sent back via SMTP. Apart from
  21. being more efficient, if the user gets a MIME message that breaks their
  22. client (e.g. by being humungously large), server-end forwarding might be
  23. the only means of passing the message on to the system administrator.
  24. Ideally it should accept an attached note, and encapsulate the original
  25. mail using MIME. But then you're half way to a 'send mail' function.
  26.  
  27. > >   6. mail sending
  28. > I suggest a review of the IETF-REMMAIL@UMich.EDU discussion to avoid rehashing
  29. > the same points over again.  It's an emotional topic; the `pro' side is
  30. > defending what they consider to be the side of simplicity (of a sort) and
  31. > authentication (again, of a sort)
  32.  
  33. I guess 'draft message handling' would be more accurate. I wouldn't
  34. particularly mind if a client had to extract draft messages out of the
  35. IMAP2 server and then post them off using SMTP. What I am trying to get
  36. out of is a situation where a user is tied to one system because all
  37. their drafts are stored there. Our users want to treat mail like a
  38. telephone network - walk up to the nearest PC or Mac and there you are,
  39. complete with draft messages, user preferences etc.
  40. From imap-request@cac.washington.edu  Tue Sep  1 14:21:53 1992
  41. Received: from mx1.cac.washington.edu by akbar.cac.washington.edu
  42.     (5.65/UW-NDC Revision: 2.27 ) id AA12855; Tue, 1 Sep 92 14:21:53 -0700
  43. Received: by mx1.cac.washington.edu
  44.     (5.65/UW-NDC Revision: 2.27 ) id AA29616; Tue, 1 Sep 92 14:21:48 -0700
  45. Errors-To: imap-request@cac.washington.edu
  46. Sender: imap-request@cac.washington.edu
  47. Received: from PO5.ANDREW.CMU.EDU by mx1.cac.washington.edu
  48.     (5.65/UW-NDC Revision: 2.27 ) id AA29608; Tue, 1 Sep 92 14:21:46 -0700
  49. Received: by po5.andrew.cmu.edu (5.54/3.15) id <AA10601> for IMAP@cac.washington.edu; Tue, 1 Sep 92 17:21:43 EDT
  50. Received: via switchmail; Tue,  1 Sep 1992 17:21:42 -0400 (EDT)
  51. Received: from hogtown.andrew.cmu.edu via qmail
  52.           ID </afs/andrew.cmu.edu/service/mailqs/testq0/QF.Uecxu4200WBwA0Y1k9>;
  53.           Tue,  1 Sep 1992 17:20:04 -0400 (EDT)
  54. Received: from hogtown.andrew.cmu.edu via qmail
  55.           ID </afs/andrew.cmu.edu/usr7/jm36/.Outgoing/QF.secxtp:00WBwJWRpFa>;
  56.           Tue,  1 Sep 1992 17:19:49 -0400 (EDT)
  57. Received: from BatMail.robin.v2.13.CUILIB.3.45.SNAP.NOT.LINKED.hogtown.andrew.cmu.edu.sun4c.411
  58.           via MS.5.6.hogtown.andrew.cmu.edu.sun4c_411;
  59.           Tue,  1 Sep 1992 17:19:33 -0400 (EDT)
  60. Message-Id: <gecxtZC00WBwRWRp4L@andrew.cmu.edu>
  61. Date: Tue,  1 Sep 1992 17:19:33 -0400 (EDT)
  62. From: John Gardiner Myers <jgm+@cmu.edu>
  63. To: IMAP Interest List <IMAP@cac.washington.edu>
  64. Subject: Re: IMAP2 futures?
  65. In-Reply-To: <MailManager.715379910.19965.mrc@Tomobiki-Cho.CAC.Washington.EDU>
  66. References: <MailManager.715379910.19965.mrc@Tomobiki-Cho.CAC.Washington.EDU>
  67. Beak: is Not
  68.  
  69. Unfortunately, the CMU hackers have been too bogged down in issues
  70. like user surveys, requirements documents, and beginning-of-semester
  71. firefighting to get any real progress done on a mail management
  72. protocol.  
  73.  
  74. AMDS (the Andrew Message Delivery System) has the forwarding
  75. information in the "White Pages" user directory component.  Users
  76. change their mail forwarding with the same mechanism they use to
  77. change their office phone number, though many client programs provide
  78. more direct support for changing the former than the latter.
  79.  
  80. I tend to share Mark's reluctance about anything with a name starting
  81. with "X.".  There is a directory service named "CSO/ph" or similar
  82. that seems simple.  I haven't examined it in detail, but I believe it
  83. deserves looking into.
  84.  
  85. -- 
  86. _.John G. Myers        Internet: jgm+@CMU.EDU
  87.             LoseNet:  ...!seismo!ihnp4!wiscvm.wisc.edu!give!up
  88.  
  89.